在軟體開發的馬拉松中，我們不應該只靠一套劇本演到底。根據情境驅動測試 (Context-Driven Testing) 的核心哲學，測試策略必須隨著專案的節奏、團隊的默契以及產品的成熟度靈活變換。當我們將這種想法帶入探索式測試時，便會延伸出四種風格迥異的執行方式，幫助團隊在不同的戰場上發揮最大戰力。

以下是針對不同情境量身打造的實踐路徑：

(1) 自由風格的探索式測試

如果你發現產品的功能已經相對穩定，且距離發布的最後期限只剩一小段路，那麼「自由風格」的 ET 會是個人的最佳選擇。這種方式不設定繁瑣的規則，給予測試者極大的空間去發揮直覺。

這類實踐通常建議在學習完一系列專業測試方法後進行，且測試人員需要投入至少一天以上的專注時間，將精力集中在特定的功能模組上。雖然它看似自由，但其實非常考驗測試人員的技術底蘊與觀察力，能幫助我們在平穩的表面下挖掘出那些隱藏的最後漏洞。

(2) ET 主導與 ST 輔助

當團隊對產品領域具備深厚知識，且成員都是理解探索式測試思維的高手時，可以嘗試讓 ET 站上 C 位。在這種方式下，探索式測試成為了整個流程的核心，而傳統的腳本測試 (ST) 則退居二線，作為補充與驗證的手段。

這種「ET 主導」的模式需要測試領導者的信任與溝通支持，將其深植於團隊的定制化流程中。它能極大地釋放資深測試員的創造力，讓測試不再只是機械化的勾選，而是對產品深度與廣度的全面挑戰。

(3) ST 主導與 ET 輔助
在許多企業級的開發環境中，腳本測試 (ST) 依然是流程的骨幹。此時，我們可以採取「微調」的策略，將探索式測試作為某個環節的增強劑嵌入其中。

這種做法不需要對現有流程進行大改，門檻相對較低，實踐者可以靈活地在特定的測試環節中發揮 ET 的作用。關鍵在於實時觀察測試效果，一旦發現某個環節的 Bug 產出效率提高，便能及時調整策略，讓嚴謹的腳本中也能保有探索的活力。

(4) 協作型探索式測試
最後一種方式強調的是「群體智慧」。筆者曾多次在專案的最後關頭發起「缺陷大掃除」活動，邀請不同專案組的成員一起進行協作型 ET，往往能取得驚人的效果。

除了大掃除，還能舉辦「全民分享活動」，讓大家交流彼此的測試心得。而在定位難度極高的缺陷時，採取「結對測試」更是絕佳手段，透過與其他成員一起復現場景，能幫助測試人員快速補足業務知識，深入了解缺陷發生的真實情境。

情境驅動的探索式測試提醒我們，我們必須隨時關注實施的效果，並根據專案的特點來調整這幾種執行方式的權重。當你的測試策略能隨著專案呼吸時，品質就不再只是清單上的打勾，而是真正的產品力。

自由風格的探索式測試

如果你覺得傳統的測試像是在走預設好的「旅行團行程」，那麼自由風格就是「沒有劇本的冒險」。測試人員不會被一張張寫死的檢查清單綁架，而是根據當下對產品的理解，自己決定下一步要測什麼。

這種方式非常依賴測試員的「技術直覺」。雖然聽起來很隨興，但其實它比機械式的勾選檢查更具挑戰性，也更能讓測試員感到樂趣和成就感。

雖然自由，但不能亂跑。想要玩得專業，通常要考量以下幾個條件：

(1) 產品已經「夠穩」了

如果軟體還在動不動就當機、連進都進不去的階段，這種測試只會浪費時間。最好的時機是專案快要結束、功能已經大致穩定的時候，這時最適合用自由風格來找出隱藏的邊角 Bug。

(2) 測試員是個「老江湖」

執行的人必須很了解軟體測試的各種技巧（像是前面聊過的旅遊區、破舊區等模型）。就像資深導遊不需要地圖也能帶你找到秘境，厲害的測試員能憑經驗快速判斷哪裡的品質可能有問題。

(3) 給予足夠的「專注時間」

這種測試不適合零碎時間，通常建議至少投入一整天的全職時間。在不受打擾的情況下，測試員才能像偵探一樣，深入挖掘出那些腳本測試漏掉的細節。

(4) 特定的實作目的

主管可以用這種方式快速掃一遍，看看其他成員測得怎麼樣。或者當測試員學了新技術，想看看自己能不能快速想出更好的測試點子時，這就是最好的練習場。

那什麼時候該用它？根據軟體開發的進程，有三個最適合切入的時間點：

(1) 當產品剛做完第一輪測試前
在正式開始照著清單檢查之前，我們先進行一場自由式探索。為什麼要這時做？ 因為這時測試團隊對新功能還不太熟悉，透過隨意亂點、亂玩，可以快速摸透產品的個性，順便建立起測試模型。

能第一時間發現那些最明顯的低級錯誤（潛在風險），並以此為參考，調整後面的正式測試計畫。

(2) 當大 Bug 都修好、準備要上線前
這通常是產品最穩定、Bug 被修得差不多的時候。測試員已經做了好幾天的機械式檢查，難免會出現「測試疲勞」。這時換個心情，用自由探索的方式來找找那些躲在深處的「漏網之魚」。

這能幫產品做最後的「差異化檢查」，提高系統對 Bug 的免疫力，確保上線前萬無一失。

(3) 當某個功能剛修好、需要快速驗證時
假設工程師修復了同一個模組中的幾個小 Bug。這時測試員可以花半個小時，針對那個區域進行自由發揮。不僅能確認舊 Bug 真的修好了，還能順便檢查有沒有因為修復而引發新問題，對該區域的品質更有底氣。

「自由風格的探索式測試」雖然賦予測試員極大的自由度，但為了確保效率並產出高品質的結果，仍有一套建議的實施流程。以下為自由風格探索式測試的詳細進行流程：

(1) 準備階段：了解目標與風險
在正式開始點擊軟體之前，測試員需要花費大約 1 至 2 小時 進行「熱身」，這是為了建立對產品的全局觀。

投入時間查看產品需求規格說明書（PRD）和原型，了解產品設計的初衷、目標使用者以及核心背景。確定哪些是系統的主要功能模組，哪些則是輔助性或貢獻性的模組。

主動與專案組的測試人員溝通，了解哪些功能模組曾經發現較多缺陷、哪些模組相對穩定，以及目前哪些部分存在的風險較大。

(2) 規劃階段：制定戰術計畫
有了初步了解後，測試員要制定一份輕量級的「探索計畫」。這份計畫不需要厚重的文件，而是具體的行動指南。

先根據可用的測試時間，決定要進行多少個Session，並為每個Session分配具體的任務與預計用時。明確每個Session要重點探索的區域，是針對新修復的 Bug，還是針對某個特定的複雜路徑。

(3) 執行階段：邊學、邊測、邊記錄
這是整個流程的核心，測試員在此時化身為偵探，在系統中進行深度挖掘。根據計畫開始測試，一邊學習產品的實際行為，一邊觀察是否符合預期。發現問題時，應立即記錄相關場景。

使用測試筆記記錄下測試過程中產生的新思路、新發現，或者是任何直覺上覺得怪異的地方。

(4) 溝通與總結階段：分享與修正
測試不只是找 Bug，更重要的是資訊的同步與品質的評估。隨時與專案組溝通測試進展、發現的缺陷修復情況，以及過程中觀察到的產品風險。

在測試即將結束時，分析整體的產品品質與潛在風險，總結本次測試的經驗教訓。將分析與總結的成果在測試團隊中分享，讓其他成員也能從中學習。

在執行過程中，根據團隊的成熟度，測試組長（Test Lead）會採取不同的管理風格：

• 委派型：領導安排測程但不直接參與任務，適合測試人員經驗豐富且穩定的團隊。

• 參與型：領導親自參與測試任務的執行，適合初創團隊或測試員經驗尚不足的情況，以便實時優化測試策略。

這套流程確保了自由風格的測試「自由而不混亂」。透過前期的風險評估、中期的專注探索，以及後期的分享總結，測試員能將個人的直覺轉化為團隊可見的品質資產。

在實際執行時，下面有些關鍵注意事項，整理如下：

(1) 投入時間的分配與控管

A. 需求熟悉時間不宜過長：
在研發週期為 2~3 個月的專案中，建議投入 1~2 小時 熟悉產品目的與主要需求即可。若花費過長路徑去了解複雜業務的具體實現過程，會導致投資回報率降低。

B. 確保足夠的專注時間：
要進行自由式探索，建議至少需要 一天以上 的全職投入時間與精力，並具備合適的測試技術要求。

(2) 溝通與資源利用

A. 測試被阻礙時立即尋求幫助：
由於探索式測試人員可能對需求細節不夠清楚，若遇到操作流程無法進行的情況，應立即與原專案組測試成員溝通。敢於提出問題並快速解決阻礙，是確保測試順利的關鍵。

B. 善用優勢資源與數據：
對於複雜系統，應利用原專案組的優勢，了解是否能 共享測試數據 或協助準備數據，以避免在數據準備上花費過多時間，從而削弱探索式測試的創造性。

C. 進行結對測試（Pair Testing）：
由兩名測試人員組成一對，在同一台電腦上進行測試，通常能激發更多更好的測試思路。

(3) 記錄與品質回饋

A. 記錄所有疑似缺陷：
對於無法確定是否為缺陷的問題，一旦發現應立即記錄症狀。在當天測試結束後，再與原專案組人員溝通確認，並每天發送包含優先級的缺陷報告。

B. 重點關注用戶體驗：
需關注產品是否易於操作、提示是否清晰。若產品體驗較差導致測試困惑，應向負責人提出此問題的重要性。

C. 邊學習邊記錄靈感：
在測試執行中，應透過 測試筆記 隨時記錄產生的新思路與新發現。